web

Review 2021 프런트엔드, 그리고 2022

29 min read|22. 1. 3.

jamstack_thumbnail

Intro

2021년 프런트엔드 개발 생태계에서 발생한 몇몇 이벤트들을 되돌아보고 올해 2022년에는 어떤 관전 포인트가 있을지 이야기해보려고 해요.

계기

작년 회고에 나만의 2021 프런트엔드 관전 포인트라는 섹션을 썼었는데 타율이 꽤 높은 것 같아 아예 별도 포스팅으로 작성해봤어요.

이런 글은 빠르게 발전하는 생태계 속에서 하루 하루 고군분투 하는 평범한 개발자 입장에서 작성하는 것이 좋을 것 같지 않나요? 그래서 제가 감히 생태계를 예단해보고자 합니다.

제 식견이 좁아 프런트엔드 개발 생태계의 모든 부분을 다루지 못하고, 다소 편향되게 기술할 수 있음을 먼저 알려드리며 양해를 구해봅니다. 이 포스팅은 농담 반, 진담 반으로 작성될 예정이니 재미로만 읽어주세요.

'지난' 2021 관전포인트 다시 살펴보기

  • Rome은 babel을 비롯한 FE 개발 환경을 단순화할 수 있을까?
    • 9월 21일 rust로 작성된다는 소식이 있었어요
    • 진행 상황을 보아하니 올해도 무리가 있어보여요. 부분적인 사용은 가능할 것 같아요. (lint)
    • 기대했던 단순화된 FE 개발환경은 오히려 더 복잡해진 느낌입니다. 하지만 더 좋은 방향인 것만은 분명해보여요.
  • 리브랜딩된 ReScript는 FE 개발 파이를 어디까지 잡아먹을까?
    • 들여다 볼 시간이 없어서 관련 소식은 잘 모르겠어요.
    • 메인스트림으로 합류하기에는 아직 무리가 있어보이긴 해요. JavaScript에서 TypeScript로 넘어갔을 때보다 러닝 커브가 더 크게 느껴져서 technical burden을 어떻게 극복할지가 관건일 것 같아요.
  • Deno는 FE 개발 파이를 어디까지 잡아먹을까?
    • 둘리가 귀엽다는 것 말고는 이 쪽도 잘 모르겠어요...
    • 들려오는 소식이... 딱히 없었던 것 같아요. (사실 귀기울이지 않았던 것)
  • React의 Server Component는 FE 개발을 얼마나 바꿀까?
  • Vercel은 얼마나 내 개발을 편하게 해주려나?
    • 제 눈엔 인피니티 스톤을 모으는 타노스로 보여요. 아무튼 엄청난 회사가 된 것 같아요.
  • 누가 monorepo 도구 제대로 좀 만들어줬으면 좋겠는데 언제 나올까?
    • lerna는 yarn workspace를 사용하여 대체할 수 있었지만 여전히 관리에 손이 많이 가고 yarn은 사용이 불편해요.
    • 오히려 모노레포 관리에는 pnpm이 더 좋게 보이기도 하는데, 사용해보지 않아서 잘 모르겠어요. 관리하고 있는 monorepo를 pnpm으로 마이그레이션 해보거나 nodeLinker로 pnpm을 사용해볼까 해요.
    • 생태계가 yarn berry를 반기지 않는 것 같아서요
    • 팔머형이 maintain 하던, 이젠 스톤 중 하나가 되어버린 turborepo도 있네요. (vercel 섹션에서 다룰게요)
  • Redux는 어느 정도 사라질까? 이 자리를 recoil이 가져가려나?
    • But then RTK responded???
    • 처음 봤을 땐 혼종이라고 생각했어요, 위 글에도 동의하지 않았구요. 그러나 Redux 정말 좋은 도구라고 생각해요. 뭐든 잘쓰면 좋죠.
    • recoil은 아직 0.5 버전이긴 한데, 하드하게 써보진 않았어요.
  • CSS-in-JS emotion 말고 다른거 없을까? ~~facebook이 만들어주면 안되나?~~
    • stateofcss2021 기준으로 봤을 때, 만족도 측면에서 emotion이 많이 내려왔어요. 하지만 여전히 사용은 높은데요, 개인적으로 너무 좋게 사용했지만 삽질을 많이 한 라이브러리라 공감이 많이 되네요.
    • modulz 팀에서 만들고 있는 stitches가 생각보다 생각보다 마케팅을 못하고 있지 않나... 하는 생각이 드네요.
    • facebook이 stylex를 오픈소스 할 수도 있지 않을까 생각이 들어요.
    • CSS-in-JS 라이브러리들을 보면서 뭘 봐야할지 모르겠다면 이 글 일독을 추천해요.
  • ~~이 나라에서 IE는 언제 사라질까?~~
    • 저희 팀도 내년부터 지원 중단 안내를 할 예정입니다! (야호...)

Rust, 그리고 Go

Babel의 집권으로 태평천하를 누리던 프런트엔드 왕국에 두 외부 세력이 등장하니...

Rust (https://www.rust-lang.org/)

제가 Rust를 마주한 것은 Vercel에서 next-swc라는 프로젝트를 공개했을 때였어요. 그래서인지 kdy1님이 운영하고 계시는 swc를 필두로 프런트엔드 개발 환경에 rust가 넘어왔다고 느꼈어요.

그러자 하나 둘씩 rewritten 되었다는 소식이 들려오네요? (역시 트렌드를 이끄는 자가 되기엔 틀린 것 같아요.) 위에서 이미 언급한 Rome 이라는 프로젝트부터 익히 들어 알고 있던 relay-compiler, GitHub Search Engine 등 JavaScript일 필요가 없는 코드들이 약속이라도 한 듯 rust로 re-write 되었죠.

2017년에 이런 밈이 돌았는데요,

JavaScript Is Eating The World

2021년엔 “Rust is eating the javascript world”가 되면서 rewritten rust라는 밈이 유행했습니다.

Rust 관련 소식은 한국 러스트 사용자 그룹에서 듣는게 더 정확하고 빠를 것 같아요. 저도 디스코드에 들어가 있긴 한데, 아는게 없어서 눈팅만 하고 있어요. Next.js가 Rust를 선택한 이유는 Vercel의 Head of Developer Relation, Lee Robinson이 작성한 글을 추천드립니다.

Go (https://go.dev/)

Vite, esbuild 등의 진영도 있어요. 아시다시피 이 진영은 Go로 작성되어 있는 도구들을 말해요. 그리고 다음 섹션에서 소개할 Remix도 esbuild를 사용하는 Go 진영이예요. 최근 vitest와 같은 도구들도 등장하면서 Go 진영이 더 단단해질 것 같아요.

제 눈에만 Rust와 Go, 이 둘이 양강구도로 보이나요?

왜 하필 지금?

esbuild는 2020년부터 진행되었고, swc의 첫 커밋은 2017년이었어요. 웹이 충분히 복잡해졌다고 공감대가 이뤄지고 나서 메인스트림에 올라온 것이 아닐까? 생각이 들어요.

Vercel

zeit이라는 작은 소년은 나중에 커서...

Rich harris 그리고 구루급 인사들의 합류

rollup을 만들었고 최근엔 svelte를 만든 Rich harris가 Vercel에 합류했어요. 이 소식 뒤에 바로 Vercel의 투자 유치 소식이 들려왔는데, 커뮤니티에서는 Rich harris영향력이 이 정도라고? 하는 이야기도 떠돌았어요.

formik으로 유명한 jaredpalmer도 turborepo가 인수되면서 vercel로 합류하게 되었고 react core team에서도 vercel로 합류한다는 소식들이 들려와요.

이 소식은 기술과 직접적으로 관련된 소식은 아니지만 프런트엔드 개발 생태계에 큰 영향을 줬던 개발자 분들이 합류함으로써 앞으로가 더 기대되는 팀이라고 생각되게 하네요.

표준이 되어가는 Next.js?

웹앱이 계속 발전하면서 서버사이드 영역과 함께 동작해야 하는 부분이 하나씩 늘어나고 있어요. 그리고 이런 변화는 Next.js 프레임워크를 중심으로 만들어지고 있어요. (made in Vercel)

ISR(Incremental Static Regeneration) 방식의 렌더링도, Next.js에서 제공하는 Image 최적화 컴포넌트도 이와 같은 맥락이라고 볼 수 있어요. (분명 <Video /> 컴포넌트도 제공할거라 생각해요.)

이러는 와중에 React에서 Server Component라는 것이 나왔는데, 이름부터 서버네요. 그만큼 프런트엔드 개발에서도 서버사이드에 대한 부분이 많이 중요해지고 있다고 생각해요. 이 기능에 대해서는 리액트 코어팀과 Vercel이 함께 작업했다고 해요. 참고로 Vercel은 Chromium 팀과도 함께 Next.js 프로젝트를 진행하고 있어요. (https://web.dev/introducing-aurora/)

이런 부분에 있어서 Next.js의 입지는 더 단단해지지 않을까? 생각합니다. 물론 리액트와 여러 라이브러리들을 어찌 저찌 함께 사용하면 웹앱 정도야 가뿐히(?) 만들 수 있습니다만, 처음부터 서버사이드 렌더링을 고려하여 구조를 잡는다는 것이... 적어도 전 그러고 싶지가 않네요.

요즘 Java 기반의 백엔드 프로젝트에서 Servlet을 사용하지 않고 Spring Framework이나 Spring Boot를 사용하는 것처럼 Next.js도 이렇게 자리잡지 않을까요?

Remix

이러한 흐름을 비웃기라도 한 듯, 10월에 Remix 팀이 펀딩을 받으며 오픈소스로 간다는 발표를 했어요. remix는 ReactTraining이라는 팀이 만든 Enterprise 대상의 React 프레임워크 입니다. 이 팀은 사실 Remix 이전에 react-router를 만들었어요. 그리고 리액트 생태계에 많은 기여를 했고 교육과 관련된 활동을 많이 했어요. 교육을 하던 도중 자체적인 프레임워크를 만들었고 이게 잘 되어 펀딩을 받은 사례라고 할 수 있어요.

저도 구체적으로 살펴보진 못했지만 우선 react-router v6에 들어온 Outlet 개념이 가장 먼저 눈에 들어왔어요. Next.js는 별도 route를 사용하다보니 react-router를 사용하지 않아 새로운 개념이었어요.

아직 Product에 사용된 사례는 보지 못했는데요, 사이드 프로젝트에 한번 사용해보고는 싶네요. Remix를 아직 살펴보지 못하신 분은 홈페이지(https://remix.run/)에 한번 방문해보시길 추천드립니다. 정말 잘 만들었거든요.

Gatsby

이 블로그도 gatsby로 만들어졌어요. (v2에서 버전업을 따라가지 못했지만...) Gatsby가 만들어 놓은 플러그인 시스템과 이 플러그인 생태계는 엄청나다고 생각해요. JAM Stack 기반의 정적인 웹앱을 만들기 위해선 아직 Gatsby 만한게 없다고 생각이 들 정도로 독보적이라고 생각해요. (물론 빠르게 변화하는 생태계 속에서 지불하게 되는 비용은 스스로가 감당해야 하는...)

DSG(Deferred Static Generation)라는 렌더링 옵션을 제공하면서 끝내주는구나 싶었어요. 새로운 Blog Management System을 만들 계획인데요, 아마도 Gatsby로 만들 것 같아요. (이 템플릿은 archive 할 것 같아요.)

아 참, Gatsby도 Gatsby Cloud라는 Hosting 서비스를 시작했어요. 이 블로그는 Netlify 기반으로 호스팅되고 있는데, 블로그를 옮기면서 호스팅 서비스도 바꿔볼 예정이어요.

Design System Framework

프런트엔드 개발자이다보니 잘 만들어진 디자인 프레임워크에는 자연스럽게 눈이 가더라구요. 이 프레임워크는 어떻게 인터페이스를 설계했나 하나씩 살펴보고 차이점을 발견하는 재미도 쏠쏠합니다. 그 배경을 이해하면 코드를 바라보는 관점이 하나 더 늘어난 것 같아서 재미있기도 하구요. 아래는 눈여겨봤던 디자인 시스템 프레임워크들입니다.

MUI

Google의 Material Design 철학을 구현한 Material-UI 라는 프레임워크가 MUI라는 이름으로 리브랜딩 됐어요. 리브랜딩 과정에서 css-in-js 솔루션을 선택하는 과정이 Issue에 있는데 흥미로운 스레드 중 하나였어요.

새로운 릴리즈를 소개하면서 Improvement DX라는 부분이 흥미로웠는데요, 이 부분은 뒤에 화제가 됐던 키워드에서 다뤄볼까 해요.

chakra-ui

좋은 인상으로 남은 디자인 시스템 프레임워크이고 Concept도 많이 참고할 수 있던 오픈소스라서 한번 소개해봅니다. 사이드 프로젝트에서도 잘 사용하고 있고 참 잘 만든 디자인 프레임워크 인 것 같아요.

radix-ui

시스템 아키텍처가 가장 마음에 드는 디자인 프레임워크인데요, DX를 참 잘 고려하지 않았나 싶어요. stitches라는 CSS-in-JS를 만들고 있는 modulz에서 만든 물건이예요. 디자인 시스템을 여러 계층으로 나누어 CSS-in-JS부터 만든 팀입니다. primitive 라는 레이어에 대한 철학도 많은 도움이 됐고 radix에서도 Component Casting 하는 부분이나 컴포넌트를 합성하는 일관된 인터페이스 등 배울 점이 참 많았어요.

tailwindcss

솔직히 처음에 나왔을 때, 왠 찐따같은게 이렇게 인기가 많은거지 싶었어요. 익숙하지 않은 인터페이스에 스타일 하나 추가할 때마다 이건 도대체 뭘로 축약해놓은거야 하며 찾아보는 좋지 않은 경험이 있었는데 다 옛말이더라구요. 이젠 어엿한 반 표준이 되어버린 것 같기도 해요. 3.0이 릴리즈됐다고 해서 봤는데, 일단 홈페이지는 아주 기가막히게 해놨더라구요. 자매품으로 나온 Twind 친구도 많이 쓰고 계신가요?

기타

소개는 하고 싶은데 딱히 첨언할 내용이 없네요.

그 외, 화제가 됐던 키워드

디자인 시스템

많은 회사들에서 자신만의 디자인 시스템을 구축하려고 하는 것 같아요. 제가 속해있는 팀도 훌륭한 디자인 시스템 기반으로 제품이 만들어지고 있어서 디자인 시스템이 가져다 주는 이점은 누구보다 잘 알아서 올바른 방향이라고 생각해요.

근데 시스템을 처음부터 만들기엔 세상에 좋은 제품들이 너무 많이 있고, 회사는 한정된 리소스를 임팩트의 크기에 맞게 분배해야 해요. 디자인 시스템도 위에서 소개한 radix처럼 레이어를 나눈다면 token 기준으로 시스템 자체를 generate 해주는 무언가가 필요한 시점이 아닐까 생각이 들어요.

디자인 시스템은 자체 결과물보단 과정과 운영이 더 중요하다고 생각해요. 이와 관련혜서 김혜성님이 디자인 시스템의 성공과 실패에 대한 6가지 질문이란 글을 번역해주셔서 공유해봅니다.

DX

DX는 Developer Experience의 줄임말입니다. (디지털 트랜스포메이션 아님) 개인적으로도 관심있는 영역이기도 한데요, 그만큼 개발자 경험이 중요해진 것이라고 생각해요. 이제 리소스가 너무 많아요. 보편적인 기능을 구현하는 라이브러리, 프레임워크들은 대부분 필요한 그 기능을 잘 구현하고 있어요. 다만 이 구현체를 사용할 때 어떤 경험을 전달하는지 중요해졌어요.

Easy to use. 쉽게 사용할 수 있는지는 이제 기본이 됐어요. 최근에 나오는 라이브러리나 프레임워크들은 왠만하면 CLI를 제공해서 프로젝트를 스캐폴딩(scaffolding)할 수 있도록 해요. Breaking Change 같은 경우는 lint를 제공하여 마이그레이션을 돕는다든가 jscodeshift를 통해 마이그레이션 CLI를 제공하기도 해요.

Composable and Customizable. 사용함에 있어서 얼마나, 어떻게 열려있는지도 중요하죠. 다른 무언가 함께 사용할 수 있는지, 내부를 override 할 수 있는지 트레이드 오프를 잘 계산해서 설계해야 사용하는데 불편함이 없습니다. 이 기능을 대체할 무언가는 많은데, 사용하는데 불편하다면 사용할 이유가 없는 것이죠.

그러면서 Consistent. 일관된 인터페이스를 제공해야 하는데, 원래도 중요했던 인터페이스가 더 중요해졌어요. 일관된 인터페이스는 예상 가능하여 좋고 이것은 개발 생산성에도 영향을 미친다고 생각해요. 동일한 기능을 구현하려고 하는데 인터페이스가 다르다면 매번 헷갈리겠죠? 당연한 것처럼 들리지만 다양한 기능을 구현하다보면 놓치기 쉽다고 생각이 들어요.

근데 이제 Faster. 빠르기 까지 해야하는거죠. 컴파일도 빨라야 하고 런타임에서도 빨라야 하고.

NoCode

제가 속해있는 팀에서도 관련 작업이 한참입니다. 반가우면서도 한편으론 내 밥벌이가 사라지는 것은 아닐까? 하는 생각에 살짝 불안해요. 그래도 옆에서 보면 아직까진 괜찮아 보입니다. 오히려 제 생산성을 한층 끌어올려줄 훌륭한 도구로 맞이하려 합니다.

다만 Framer의 발전은 심상치 않습니다. 왠만한 정적 웹 사이트는 개발자 없이 디자인 레벨에서 바로 배포가 가능해요. sites라는 기능인데요, 토스의 브랜드 리소스 센터 홈페이지(https://brand.toss.im/)가 이 기능을 사용하여 만들어졌습니다.

이제 제품을 만드는게 아니라 제품을 만들어내는 무언가를 만들어내는 무언가를 만들어야 할 것 같아요. 위에서 언급한 디자인 시스템을 만들어주는 무언가와도 비슷한 맥락인 것 같아요.

web3

2021년 하반기엔 온통 이 얘기 뿐이었어요. 저도 가만히 살펴보고 있는데요, 아직 누군가에게 정확하게 설명할 정도는 되지 않고 관심이 있는 사람이 조금 살펴본 정도로만 알고 있어요.

아직 풀리지 않은 의문이 있는데요, 혹시 아시는 분 계시면 댓글로 알려주세요!

  • 왜 갑자기(suddenly) 지금인가?
    • 단순 돈의 흐름 때문인가?
  • 해결하고자 하는 문제가 정말 사용자들이 문제로 인식하고 있는 것인가? (미래에 문제라고 인식하려나?)

이 주제에 대해선 Stay tuned 입장이고 흥미롭게 본 프로젝트 몇 가지 소개해드리고 마무리하려고 해요.

2022년, 나만의 관전 포인트

  • Rust 진영과 Go 진영이 어떻게 공존할까
  • 모든 개발환경이 Rust로 변할까? 프런트엔드 개발자들은 두 가지 언어를 기본으로 다뤄야 하는 것일까? 새로운 직군이 생겨나는 것인가?
  • Rust도 꽤 자리를 잡았겠다, wasm으로 좀 더 메인스트림으로 올라올 수 있을까?
  • Vercel을 빼고 더이상 프런트엔드 생태계를 논할 수 없게 되었어. 앞으로의 행보가 너무 기대대되는 부분. (타노스가 아니라 우리를 구원해줄 어벤져스였길 바래.)
  • 작년에 stitches를 주목했다면 올해는 vanilla-extract를 살펴보려고 해. Shopify가 Sass 대신 이 녀석을 썼거든! 아니면 stylex 기다려봐야지...
  • Remix가 얼마나 성장할까? 설마 Vercel이 또 acquire...?
  • Framer는 No-Code로 어디까지 가능하게 할까? 이미 정적 사이트까진 뚝딱인 것 같은데... 어드민 Generator Framework 같은 기능이 나올 수도 있을까?
  • 제품을 만들어내는 무언가를 만들어내는 무언가가 나올 것 같아. 최근엔 retool 이라는 제품을 흥미롭게 봄
  • 예상 외로 Module Federation에 대한 이야기가 적었던 것 같아. 올해엔 좀 더 발전될 부분이 있으려나? (Vercel이 Next.js에서 밀어줄 때가 된 것 같은데 말이야... vercel/next.js#16368)
  • ESM으로 가즈아. 오픈소스 줍줍하기 딱 좋을 듯. (ESM과 관련되서는 이 글을 추천해요.)
  • 애증의 yarn berry. 꾸준히 좋아지고 있다만 메인스트림을 조금만 벗어나면 PnP를 지원하지 않는 상황. 심지어 Next.js에서도... issues/32115 메인테이너들이 전부 Meta에서 나왔다던데...
  • Storybook은 DX가 너무 구려... 하지만 기능 자체는 너무 좋고... Vite 기반으로 잘 나와줬으면 하는 작은 바램이... (vitebook)
  • (Joke) Docusaurus 정식 릴리즈 올해 안에 할 것인가!
  • 음... web3 이거 뭘까?

마무리

정리하다보니 FEConf2021에서 다룬 내용들이 꽤 많이 보입니다. 놓치신 분들은 FEConf Youtube Channel에서 모든 세션을 다시 보실 수 있어요.

아무래도 1년을 돌아보는 기준이 트위터에 아카이빙해둔 것을 기준으로 하다보니 제 견해로 가득찰 수 밖에 없던 프런트엔드 생태계 회고였던 것 같습니다. (그래서인지 Vue, Angular, Svelte, React Native, Node 진영, GraphQL 관련 등은 잘 몰라서 내용이 거의 없네요...) 재밌게 봐주셨다면 구독, 좋아요 부탁드리구요, 내년 이맘 때 이 컨텐츠로 다시 찾아올게요 :) (내년엔 미리 미리 준비 좀 해둬야겠어요 ㅠㅠ)

여러분들이 생각하시는 올해 2022년 관전 포인트는 무엇이 있나요? 댓글로 알려주시면 내년 이맘때 같이 다뤄보겠습니다!